Electronic Data Interchange (EDI) refers to an electronic exchange of business documents in a standard electronic format between trading partners. The most common documents exchanged via EDI are purchase orders, invoices and other payment documents. Because EDI documents are processed electronically by computers, a standard format is necessary so that the computers will be able to process the documents. The standard format describes what each piece of information is and in what format. The exchange of EDI documents is oftentimes between two different companies, referred to as trading partners or business partners. For example, in the healthcare industry, a healthcare provider and payer (such as an insurance company) are trading partners.
ANSI X12 represents a standard data interchange format across industries. In the X12 EDI standard, documents are assigned a 3-digit number for invoices, catalogs, healthcare claim, purchase order, etc. X12 uses serialization which requires a serialized sequence of values where delimiters separate elemental information. Serialization has no notion of an inherent structure hierarchy and therefore relationships among the serialized data stream are ill-defined and ill-derivable without a users inherent knowledge or unique dedicated processing of a pre-identified serialized stream.
To utilize X12, a programmer must characterize each transaction uniquely, requiring the programmer to be skilled in understanding X12 format, especially in the context of the specific transaction the data stream is to be processed, making and interpreting the calls and also writing the transaction processing. The current methodology is complex, non-intuitive, non-relational, and requires unique process calls throughout the workload.
Current systems rely on hard coded parsing rules, brittle data transformation processes and extensive human intervention for troubleshooting an issue when a process breaks down, thereby causing a manner that a change in the expected data stream or a change in the process to be performed is hard to anticipate and therefore a changed data stream or a changed process would require a distinct new set of hard-coded parsing rules. Single purpose hard coding the parsing rules creates maintenance havoc for engineers when any update to a schema is needed. Also, implementing a new functional process schema requires rewriting a major chunk of code and thereby creating a one-to-one relationship between a parsing engine and a particular functional process schema.
The brittle code problem was compounded by the fact that an interchange between trading partners may have a particular set of rules established. For example, an EDI business analyst is usually required to troubleshoot anything wrong or even a simple update to the interchange process, since they know the contract was established. Special purpose hard coded rules also leads to difficulties maintaining one-off rules that affect an entire code base.
These and other drawbacks may be present in current systems.